Byl vydán Mozilla Firefox 159.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 159 bude brzy k dispozici také na Flathubu a Snapcraftu.
Nasazení softwaru, který nyní používá ve svých autech pro čínský trh, zvažuje automobilový koncern Volkswagen také v Evropě, kde by se mohl používat v budoucích vozech značek Volkswagen, Škoda a Cupra. Základem pro budoucí evropské modely by se mohla stát takzvaná China Electronic Architecture, elektronická architektura vyvinutá pro čínské modely ve spolupráci s tamní automobilkou Xpeng.
Vedoucím brněnské pobočky Red Hatu se stal Radek Vokál [LinkedIn].
Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »Článek na blogu APNIC vysvětluje, jak správně vytvářet a používat ASPA záznamy — podepsané objekty v RPKI, které uvádějí, kteří poskytovatelé směrování jsou pro dané autonomní číslo (ASN) oprávněni. Síťoví operátoři je mohou využít k ověřování tras BGP a k odhalování úniků tras či podvržených tras.
Byla vydána (𝕏) verze 8.0.0 open source programu pro prolamování hesel hashcat (GitHub, Wikipedie). Přehled novinek v příspěvku v diskusním fóru a pdf.
Byla vydána (𝕏, Bluesky) nová verze 2026.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 6 nových nástrojů v oficiálním oznámení na blogu.
Do konference přišlo celkem 1537 emailů, nejvíce jich poslali Andrew Morton, William Lee Irwin III a Adrian Bunk.
29. črv - 8. črc
Linas Vepstas napsal:
Firmware může hlásit chyby kdykoliv a není to neobvyklé ani při bootu. Jenže tyto zprávy nejsou k ničemu do chvíle, kdy naběhne rtasd, což je poměrně pozdě. V důsledku toho jsou chyby firmawaru během bootu tiše ignorovány.
Tenhle patch je alespoň vypíše pomocí printk, takže se objeví v boot.msg/syslog. Existují ještě dva logovací mechanismy, které jsem radši nechal na pokoji, protože nerozumím jejich chování. Především nvram není povoleno až do pozdní fáze bootu... Ale jaký má pak nvram logování smysl, jestli ne zachytávat zprávy, které se objevily časně během bootu?
Paul Mackerras odpověděl: Printk vypisující chyby je otravné a nezdá se mi to příliš přínosné vzhledem k tomu, že jde jen o nečitelná hexová čísla, kterých může být opravdu moc. Musí existovat lepší způsob. Dát to do nvram se mi zdá jako lepší možnost. Neznám důvod, proč bychom nemohli nvram používat hned zkraje.
Jake Moilanen poznamenal: nvram můžeme inicializovat velmi brzy, ale události v nvram uložené bychom neměli zahazovat, dokud neběží rtasd a ty události si nevytáhne, protože by mohlo jít o tu chybu, která minule při bootu systém shodila. Mohli bychom asi rtasd nastartovat o trochu dříve, ale nepřipadá mi, že by nás to mělo tolik trápit.
Greg KH celou záležitost považoval za diskutabilní, protože Linas by měl prostě použít syslog nebo netlink jako celý zbytek kernelu. Nevynalézejte znovu kolo.
Paul také Linasovi řekl: Tento typ problému se obyčejně řeší pomoci netlinku. Myslím, že by dávalo smysl vypisovat pomocí printk RTAS chybové události se závažností "fatal" a možná i "error". Varování a události by však měly být poslány na rtasd.
Hollis Blanchard napsal: Už jsem se na to ptal dříve a bylo mi řečeno, že neexistuje způsob, jak zjistit závažnost události bez předchozího úplného zpracování binárních dat. Byl bych nadšen, kdybych se mýlil...
Nathan Fontenot odpověděl:
Zjistit závažnost RTAS události lze a ani to není moc náročné. Podívej se na asm-ppc64/rtas.h, kde najdeš definici hlavičky RTAS události (struct rtas_error_log). Všechny RTAS události mají počáteční hlavičku obsahující závažnost dané události.
Dekódování RTAS událostí za hranicemi hlavičky je po chvilce pěkně nechutné a doufejme, že to v jádře nikdy nebude potřeba dělat.
4. črc - 14. črc
Norberto Bensa si všiml, že XFS vynuluje soubory po nekorektním vypnutí. Zeptal se, jestli existuje způsob, jak se tomu vyhnout. L. A. Walsh odpověděla, že jde o starý problém, který byl již dříve hlášen v XFS konferenci; ale dodala:
Zjevně to nelze snadno reprodukovat, nikdo nemá tušení, proč se tak děje. Prostě to dělá. I po několika synchronizacích jsou někdy soubory editované během posledních několika dní vynulovány. Dobrý důvod pro pořizování denních záložních kopií, protože ty většinou obsahují bezchybné soubory...
Kdybych jen mohla přijít na to, jak to reprodukovat... když se o to
pokusím, nic se nestane. Grrr... ví, že kontroluji! 
Chris Wedgwood během diskuze řekl:
XFS soubory nevynulovává, pouze vrací nuly místo nezapsaných úseků. Otevřete-li existující soubor a celý jej popíšete, možná během spadnutí uvidíte stará data, nebo nová data, pokud byla zapsána [flush]. Neměli byste však vidět nuly.
Hádám, že u jiných filesystémů (když se žurnálují pouze metadata) jsou bloky alokované pro nově zapsaná data většinou stejné jako nedávno uvolněné bloky, takže to vypadá, že všechno funguje, ale ve skutečnosti je to pravděpodobně pouze náhoda. XFS by se mohlo chovat podobně, ale dříve nebo později byste na to stejně doplatili, když byste dostali nesmysly místo starých dat.
Některé aplikace je prostě potřeba opravit.
L. A. odpověděla:
Nevím, jestli to nějak pomůže (pochybuji, mě to mate)... Soubory, které jsem zapsala ve vimu, a které vrátily "nuly", byly soubory napsané před 2 - 3 DNY -- přičemž čerstvější zápisy byly často uloženy bez problémů.
Kdyby to byl soubor, který jsem právě editovala, a v tu chvíli to spadlo, to bych to chápala lépe než soubory, kterých jsem se pár dní nedotkla.
Chris řekl, že podobné chování skutečně nikdy neviděl, rozhodně pak ne u souborů, které byly upraveny před několika dny. Byl si jistý, že na jeho systému by checksum skripty, které kontrolují všechny jeho soubory, něco takového zachytily. Jeho odhad v odpovědi na popis od L. A. byl, že soubory jsou skutečně nějak měněny, ale nedělá to XFS.
5. črc - 8. črc
Andrew Morton oznámil Linux 2.6.7-mm6:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.7/2.6.7-mm6/
8. črc - 14. črc
Erik Rigtorp napsal: Tento patch do swsusp přidává podporu pro bootsplash. Na kódu, který je rozhraním k bootsplash, je ještě nutné pracovat, v této chvíli je víceméně ukradený ze swsusp2. Nějaký další kód by šlo místo toho pravděpodobně přesunout do console.c.
Christoph Hellwig poukázal na to, že CONFIG_BOOTSPALSH není v současné době v oficiálním stromu jádra; takže podporovat to u software suspend je předčasné. Christoph rovněž naznačil, že CONFIG_BOOTSPALSH v hlavním stromu vítáno není. Pavel Machek odpověděl:
Ten patch nebyl určen pro hlavní strom... Ale i tak se bude hodit, protože velká distra tenhle druh věcí chtějí...
Možná by CONFIG_BOOTSPLASH nakonec v hlavní stromu být mělo. Vůbec se mi nelíbí představa dvou nekompatibilních sad háčků do swsusp....
Ale Christoph řekl: Ne. Tyhle věci nemají v kernelu co dělat. Malujte si své pěkné obrázky přes fbdev. A ten bootsplash patch od SUSE je totální humus - vždyť co musíš hulit, abys dal JPEG dekodér do jádra?
Stefana Reinauera se to dotklo a napsal:
Souhlasím, že v případě jádra 2.6 by to šlo udělat lépe díky pořádné podpoře initramfs, ale v 2.4 nebyl žádný rozumný způsob, jak vložit uživatelský kód dost brzy na to, aby byl spuštěn před inicializací framebufferu.
Na druhou stranu, ten JPEG dekodér má 8k - méně než desítky gzip/gunzip algoritmů v kernelu. Takže stěžování mi přijde trochu hloupé. Jestli chceš jen držkovat, pak běž kritizovat to, že s rozlišením 1024x768 sežere bootsplash nadobro 1.5MB paměti. Pokud něco, tak TO by dávalo smysl.
A jestli chceš retro textové hlášky nebo grafický boot, to je dozajista filosofická otázka. Dle mého skromného názoru není možné tak brzy startovat X.
Pavel pak také Christophovi řekl:
SUSE verzi bootsplashe jsem neviděl... Ani nechci vidět. Ale takhle má SUSE svůj mizerný bootsplash, RedHat pravděpodobně také, Mandrake asi také, atd.
A teď bude chtít SUSE splash u swsusp, RedHat pravděpodobně také, Madrake asi také, atd. Nechce se mi trápit se třemi různými sadami háčků do swsusp.
Takže... kdyby si pročištěný bootsplash našel cestu do jádra, mohlo by to zmírnit množství humusu v distribucích. Aspoň by existoval jednotný způsob, jak tu věc vypnout...
Christoph odpověděl: Red Hat to dělá správně, protože používá program, který využívá fbdev. Zároveň také nemají žádnou podporu pro swsusp, což dává docela smysl, když vezmeme v potaz, jakým tempem se ten kód i nadále mění.
V originálu Kernel Traffic 270 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz